@richardpark-msft , can we make the extension to return this as part of the error? or even make the extension to invoke azd init ?

Looking for a way to shift left this from happening to preventing

From talking with @bob-okeefe, it sounded like the steps he went through were:

1. azd login
2. Run the coding-agent extension
3. Error back from AZD cred (internally) that says the refresh token is expired

So then he azd init'd and it worked.

Does azd init do something differently from azd login?

Interesting.
It might make a difference if you were asked to pick a subscription - or if the azd init invoked the azd auth login

Do we have more details about the number 3? I what was trying to use the credential?

Any ideas @weikanglim ? -

But then, @richardpark-msft , there's not expectation from the extension around running azd init first? If not, we should not add this note and instead make this an issue/bug to investigate (try to repro).

I was always asked to pick a subscription when I ran azd coding-agent config. I would choose my subscription and my repo. However when I got to the MI step and said to create a new MI it always failed. I was only able to resolve this after running azd init.

See attached.

When using debug I got this:

BTW, I only figured out that I had to run azd init because when I was using Copilot to troubleshoot this it suggested running azd env set AZURE_SUBSCRIPTION_ID . When I did this I got this error:

ERROR: no project exists; to create a new project, run azd init

After the azure.yml file was created I was able to run azd coding-agent config successfully

Apparently those errors are coming from when I call into the 'azd' PromptClient/PromptServiceClient:

• PromptClient call
• PromptServiceClient call

I was wondering, at first, if perhaps I was messing up some subscription or passing in a bad credential, but this is within 'azd' itself.

But then, @richardpark-msft , there's not expectation from the extension around running azd init first? If not, we should not add this note and instead make this an issue/bug to investigate (try to repro).

There isn't - I remember us talking about this. I don't use any azd logic to detect or use any project, so it should be safe.

Do you happen to have subscriptions across multiple tenants? I wonder if doing azd auth login --tenant <tenant-id> would've helped in this case. It's odd you still got an expired token error right after running azd auth login.

did you ended up running azd env set AZURE_SUBSCRIPTION_ID xxxxxx ?
If yes, that's how it was fixed.
You had to run azd init ... but only to be able to run azd env set ... - to have an azd env where to set the sub-id.

A similar approach is to set AZURE_SUBSCRIPTION_ID as system env var (not at azd's env) and that would also work.

The issue is that azd is trying to use a token for the wrong tenant. When you set the sub-id, azd resolves the right tenant where that sub belongs to.

Even thought the extension is asking for a subscription, azd is not using the response to use that sub/tenant for the following events - instead it is using the credential provider which resolves to use a different token.
We need to make the extension to use the subId selected to re-set the credential provider - I'll see if that can be done (time to chat to the AI ...) - I'll be back to you...

Confirmed the hypothesis — the extension uses Subscription.TenantId (resource tenant) instead of Subscription.UserTenantId (user access tenant) when creating the AzureDeveloperCLICredential. For multi-tenant/guest users these differ, causing "refresh token expired" errors.

Filed #7077 with fix at #7078.